1. Field of the Invention
The present invention generally relates to the implementation of computer networks, and more particularly, to a method and system for reordering packets received from a high speed data channel.
2. Background Description
In a network system, a network handler receives packets from a high-speed network, performs routing actions and then passes the processed packet to an output port for delivery to its intended destination. Packet processing is performed in accordance with one or more specific network protocols. When packets are received out of order, some protocols and classes of service, for example, Fibre Channel Class 2, require delivery of packets in proper sequence. The protocol handler provides a mechanism to establish the proper order of packets and to deliver them in the sequential order.
A straightforward technique for reordering packets is to use a packet table. For each packet received a table entry is generated containing the “sequence count” and the address pointing to the memory area where the packet resides. The sequence count specifies the sequential position of the packet within its flow. Once all packets from the flow are received packets are sorted by sequence count. This approach is inefficient in terms of both memory usage, because of a possibly large number of packets in a flow, and processing time required for searching and sorting the entries. In addition, sorting is only possible when all packets have been received, requiring possibly high buffering resources.
Another approach is to use a reorder table with depth “n”. Similar to the approach described above, for each received packet there is created an entry in the reorder table containing the sequence count and memory address of the packet. The table contains “n” records of the “n” most recently received packets. Once the table is full, the packet with the lowest sequence count is selected for transmission. This entry is removed making space for the next incoming packet. This approach does not guarantee that packets will always be reordered in that packet reordering is possible only if packets are not displaced for more positions than “n” entries in the table. For example, for table size 8, and for packets with sequence count starting at 20 and up received immediately after the packet with sequence count 10 (received packet sequence is “9, 10, 20, 21, 22, 23, 24, 25, 26, 27, 11 . . . ”), packets cannot be properly ordered and delivered in sequence.
In yet another approach, a table entry is recorded only if the packet is received out of sequence. In addition to the sequence count of the last frame received in sequence and memory address of the first packet in that sequence, the table entry contains also the length of data received in order, i.e., the sum of data of all packets from that sub-sequence. For example, for packet sequence “10, 20, 21, 22, 23, 11”, for the sub-sequence 20 to 23, an entry is created containing the sequence count of the last packet in the sub-sequence (23), the address pointing to the first packet in the sub-sequence (20), and the length of all data contained in packets 20 to 23.
Proper order of packets is determined by searching for the table entry with the lowest sequence count and accessing the data of given length from the given memory location. This approach requires large contiguous memory area to store all packets received in sequence, which can be significant. In addition, packets from various flows are received intermixed, so for each flow a separate memory area has to be provided to store all packets received in sequence for that flow. As it is not known in advance how many packets are in a flow and how many packets are in sequence, this technique leads to extremely inefficient memory utilization.